Notes/Domino Fix List
 |  |
| SPR # SKLZ4G7L5T | Fixed in 5.0.12; 5.0.10 release | Template fix: pernames.ntf |
Product Area: Client; Template Technical Area: Templates - Personal NAB Platform: Cross Platform
SPR# SKLZ4G7L5T - Fixed a problem where personal address book save conflicts were deleting multiple entries.
Technote Number: 1087244
Problem:
The issue can occur if a QueryClose event exists in the database and it is
forcing a save. Examples:
Call doc.Save(True,False,True)
or
Call doc.Save(True, True)
Information on the Save method from the online help:
Save method
Saves any changes you have made to a document.
Defined in
NotesDocument
Syntax
flag = notesDocument.Save( force, createResponse [ , markRead ])
Parameters
force
Boolean. If True, the document is saved even if someone else edits and saves
the document while the script is running. The last version of the document that
was saved wins; the earlier version is discarded.
If False, and someone else edits the document while the script is running, the
createResponse argument determines what happens.
createResponse
Boolean. If True, the current document becomes a response to the original
document (this is what the replicator does when there's a replication
conflict). If False, the save is canceled. If the force parameter is True, the
createResponse parameter has no effect.
markRead
Boolean. If True, the document is marked as read. If False (default), the
document is not marked as read.
Return value
True indicates that the document was successfully saved
False indicates that the document was not saved
Possible Workarounds:
Do not force the save, or remove the QueryClose event if possible, or do some
sort of file locking like via LotusScript. Refer to the document, "How to Lock
Documents via LotusScript to Prevent Simultaneous Access" (#155070), for more
information on how to lock a document to prevent simultaneous access by two
users.
Fix and Caveats
A fix was created in Notes/Domino 5.0.10 to resolve this issue. However,
since the fix was created it has been found that the fix may actually introduce
document level corruption. A 5.0.10 hotfix is available which undoes the
5.0.10 fix. Additionally, the 5.0.10 fix has been removed from Notes 5.0.11.
An additional fix is currently being researched to resolve the issue.
Below are the problems that may be encountered, which could indicate this
corruption has occurred. It is possible that these issues could occur in
releases other than 5.0.10 if the document is replicated from the non-5.0.10
system to the 5.0.10 system and then back to the non-5.0.10 system. The issue
occurs in cases where a document with a self-referencing $REF field is
replicated from a pre-5.0.10 server to a 5.0.10 server. On the 5.0.10 server
when a server task, such as Fixup or Compact, acts on the document it becomes
corrupt.
One may observe the following on the Console:
NSFDbOpen: File '<path\db name>' is CORRUPT - Now Read-Only!
or
**** DBMarkCorrupt(DbFixup: invalid slot found, could not be repaired,
DB=<drive:path\filename.nsf> TID=[017E:0002-00CE] ***
or
<date time> Error compacting database <filename.nsf>: 03:F5
The following Fixup errors may be observed in the log:
Document NT00000AAA in database <path\filename.nsf> is damaged: Field length
stored in document is incorrect (Field Body, Datatype 0001)
Document NT00000AAA in database <path\filename.nsf> has been deleted
or
Document NT00000AAA in database <path\filename.nsf> is damaged: Document has
invalid structure
Document NT00000AAA in database <path\filename.nsf> has been deleted
or
Database is corrupt -- Cannot allocate space
The following Compact errors may be observed in the log:
Error compacting database <path\filename>: 03:F5
or
Error compacting database <path\filename>: Database is CORRUPT -- Cannot
allocate space
Note: If the server is not running, or replicating with, Domino release 5.0.10
and is instead running a Domino release prior to 5.0.9 then also review the
following technote which describes another issue where the noted Fixup errors
and NSFDbOpen error can occur: "Enabling Soft Deletions Results in Database
Corruption - Typically in Mail Files" (#186752).
Supporting Information:
The original issue is easily reproducible using the Personal Address Book
design:
Note: The original issue does not occur with 5.0.10.
1. In Domino R5 Designer, open a Personal Address Book.
2. Make a copy of the Contacts view and deselect/uncheck the 'Show Response
Documents in a Hierarchy' feature in the View properties. Save the new view.
In this example, the view is called "Contacts - Flat View".
3. Create and save a Contact document in the Personal Address Book.
4. Create a doclink to the Contact document, then close the Personal Address
Book.
5. Paste the doclink into a new blank memo and save it as draft.
6. Reopen the draft memo and click the doclink. The first instance of the
Contact document opens.
7. Go back to the memo and click the doclink again. A second instance of the
Contact document opens. You should now have 2 instances of the same Contact
document open.
8. Place the first instance in Edit mode and make a change to one of the
fields. Save the document.
9. Place the second instance in Edit mode and make a change to a different
field. Save the document and select 'Yes' to the dialog box with the following
prompt: "Another copy of this document was saved while you were editing it.
Save your changes also as a Save Conflict Document?"
10. Open the Personal Address Book to the Contacts view and refresh the view.
The Contact document and its associated replication/save conflict document
should not be visible in any view.
11. Open the "Contacts - Flat View" you created in Step 1, and note that both
documents are replication/save conflicts where the first document refers to
itself in the $Ref field.
Note: In order to reproduce the corruption issue the document(s) created above
would need to be replicated with a Domino 5.0.10 Server. Once replicated, if
you ran Compact or Fixup on the database the document would then become corrupt.
Related Documents:
How to Lock Documents via LotusScript to Prevent Simultaneous Access
Document #: 155070
Enabling Soft Deletions Results in Database Corruption - Typically in Mail Files
Document #: 186752 More >
Last Modified on 01/21/2005
Go back
|